geoprobe: reject forged, replayed and spoofed geolocation input - #4271

Four defects in the RFC-16 geolocation chain accepted input that was never authenticated. Each fix has a test that fails without it.

1. Forged offsets were stored and served. geoprobe-target computed signatureValid and then never used it, so an unsigned UDP datagram to port 8923 reached the cache and location_offsets — a table the lake explorer aggregates with no filter on signature_valid, i.e. a public page. Invalid offsets are now dropped outright rather than written to a separate path: the writer has one table, an alternate one would be a schema change (out of scope), and abuse visibility comes from a Warn log instead.

While testing this I found the gate alone was bypassable. Go's ed25519.Verify does not screen the all-zero pubkey: it decodes to a valid order-4 point rather than being rejected, so with an all-zero signature the verification equation holds whenever the message hash lands on the right residue — about one message in four, which an attacker reaches by varying any field. A fully unsigned offset verified. The zero-key guard now covers every place in the measurement chain where a wire-supplied pubkey is used as the verification key: VerifyOffset, and ProbePacket.Verify / ReplyPacket.Verify in tools/twamp/pkg/signed. The fourth ed25519.Verify site, telemetry/state-ingest/pkg/server/auth.go, takes its key from device.MetricsPublisherPubKey after a successful lookup, so it is not attacker-supplied and is left alone.

Severity of the two packet-level sites, traced rather than assumed:

• ProbePacket.Verify at the reflector is not exploitable end to end today. The allowlist check runs before verification, and the geolocation program already rejects a default target_pk for inbound targets (add_target.rs:84), so the zero key cannot reach authorizedKeys. The guard removes the reflector's dependence on an invariant enforced in another program.
• ReplyPacket.Verify has real effect. LinuxSender.tryRecv pins reply.AuthorityPubkey to the expected probe key before verifying, but only on the verify=true path, which is Reply 1. Reply 0 is accepted unverified by design, and geoprobe-target-sender then calls Reply0.Verify() for audit logging — so a spoofed Reply 0 carrying a zero authority key was logged as reply0_sig=true.

2. RFC-16's replay mitigation was not implemented. MeasurementSlot was written and logged but never compared, and the only other freshness bound is receipt wall-clock, which a replay refreshes. The agent now rejects an inbound DZD offset unless its slot is within 15 min behind / 5 min ahead of the current ledger slot. The window comes from the caches on both ends: the DZD stamps offsets from a slot cached for SlotCacheTTL (5 min) and the agent compares against its own 5-min cache, so ±5 min of skew is legitimate before RPC and finalization lag; 15 min of lag leaves room for a degraded RPC without making the check meaningless. If no slot is available at all the offset is rejected — the agent cannot sign composite offsets in that state either.

Separately, offsetCache.Put used <= for best, and replacing best also resets its expiry clock, so a replayed offset held best forever. Now strictly <.

3. Unverified packets mutated per-sender reflector state. target_pk is public onchain, so ~2 spoofed packets per window could consume a paying sender's pair budget, repoint pairSourceIP, and clear its challenge nonce. The reflector verifies before touching state. Replying without verification is still allowed per RFC-16 — that path now runs off a throwaway state, so the nonce it issues authenticates nothing, and is capped at one reply per window per pubkey, since the reply is ~10x the probe size and an unlimited one would be a reflection amplifier.

4. Delinquent targets were measured forever. All-nil returns meant "scan skipped", which a completed-but-empty scan is indistinguishable from, so removing a user's last target or flipping them to Delinquent left the probe measuring until restart. discover now returns an explicit scanned bool.

Also: ICMP replies are matched on source address in addition to ID+seq.

No wire format or Borsh layout changed. RFC: rfc16-geolocation-verification.md — step 6 of the inbound flow is amended, since it stated the reflector does not verify probe signatures.

Testing Verification

• Each fix was reverted individually with its test in place and confirmed failing, then restored and confirmed passing: forged offset reaching the cache and the ClickHouse buffer; a replayed offset (slot outside the window) reaching the cache over a live UDP listener, and an equal-RTT put refreshing best's clock; spoofed probes starving a legitimate sender's pair so its Reply 1 never comes back Challenged; an empty-but-completed scan not propagating on any of the three channels; an ICMP reply from an unprobed host being credited as the target's RTT; an unsigned probe and an unsigned reply verifying.
• That revert check caught two weak tests. Because acceptance of the zero pair is message-dependent, TestVerifyOffset_ZeroPubkeyAndSignature and the first version of the probe test passed with their guard removed — their payloads hashed to a rejecting residue. All three zero-key tests now pin field values (offset slot 2, probe seq 1) that the unguarded code accepts, and each was re-confirmed failing without its guard.
• go test ./controlplane/telemetry/... ./tools/twamp/... — all pass except tools/twamp/pkg/light, which fails identically before my changes in this sandbox (TestTWAMP_Sender_* cannot write to 10.255.255.255: operation not permitted). I did not touch that package.
• golangci-lint run ./controlplane/telemetry/... ./tools/twamp/... clean.